J2EE基础－－步入J2EE架构和过程（1）

Java2企业版（J2EE）平台由四个关键部分构成：规格说明、参考实现、兼容性测试套件
和蓝图（BluePrint）计划。蓝图描绘了分布式组件架构最好的实践和设计指导方针。本
文基于Rational统一过程和BluePrint示例程序介绍一个八步骤J2EE开发方法学。通过阅
读这篇文章，你可以了解许多重要的J2EE架构的话题，并且能够扩展和修改这个简单的方
法来解决自己特有的业务问题。 

在商业世界里，我们使用Java2 企业版（J2EE）解决业务问题、开发商业软件或者提供转
包服务。如果一家公司想使用多层体系结构建造一个电子商务网站，通常在整个开发生命
周期中需要涉及到管理者、架构师，设计人员、编程人员、测试人员和数据库专家。 

为了使不同部门能高效率地工作，他们经常需要一个软件开发过程。一些经典的开发过程
包括瀑布模型、快速应用开发（RAD）和极限编程（XP）。本文我们将集中于一个流行的
软件工程过程，即Rational统一过程（RUP）。RUP提供了一个给角色分配任务和责任的严
格方法。它的目标是保证我们在预期的进度和预算内开发出满足用户需求的高质量软件。 

我在J2EE开发中使用RUP出于以下三个原因。首先，RUP以架构为中心；在将资源分配给全
面开发之前，它先开发一个可执行的架构原型。其次，RUP是迭代并基于构件的。该架构
基线通常包括一个框架或基础设施以便于通过迭代增加构件，在不影响系统其他部分的前
提下定制和扩展一个系统的功能。最后，RUP 利用一门工业标准语言--UML，可视化建模
系统的架构和构件。RUP有四个不同的开发阶段：初始、细化、构造和移交。然而，本文
从技术角度覆盖了 J2EE开发的八个必要活动，主要集中在系统架构。 

1、 需求分析 

需求分析描述系统应该做什么或不应该做什么使得开发者和客户可以签署一份原始的商业
合同。可以使用业务概念、领域术语、用例和用户界面（UI）模型形成功能需求文档。对
于非功能需求，如性能和事务，可以在需求文档附件中详细说明。根据参与项目深度的不
同，确定在纸上还是使用HTML建造高层UI模型。 

图1 展现了一个典型电子商务系统中的两个用例。查看订单（viewOrder）用例告诉我们
一个用户通过Web界面登陆系统、查看订单列表，点击链接查看特定订单的详细信息。增
加订单项（addLineItem）用例告诉我们浏览产品列表、选择感兴趣的产品并将它们添加
到购买订单中。 

按此在新窗口浏览图片
图1 订购用例 

2、 面向对象分析 

分析人员构造问题领域模型：类、对象和交互。分析应该与技术和实现细节无关，并包含
一个理想的模型。对象分析可以帮助理解问题并获得关于问题领域的知识。因为业务过程
的改变比信息技术的改变要慢得多，所以必须要维持一个不含技术细节的纯领域模型。 

这两个步骤--需求分析和面向对象分析--不是J2EE特有的；对许多面向对象方法学来说，
它们都非常通用。图2 显示了一个宠物店示例程序的高层对象分析模型。它用图例说明了
我们从需求分析用例中识别的主要概念。我们把这些概念建模成对象并标识它们的关系。 

按此在新窗口浏览图片
图2 更高层分析模型：宠物店领域 

需求和对象分析的结果是为J2EE架构的开发提供切入点。为了开发架构，可以选择一个纵
向联合部分（vertical piece）--经常是关键部分，如订单领域对象模型--进行对象设
计、实现、测试和部署。（纵向联合部分，一个RUP概念，是指系统的一小部分。起始点
是图1所示的用例子集和图3所示的领域分析模型。一个纵向联合部分的实现结果是一个全
功能的微小系统，包括UI层的JSP，中间层业务对象如EJB和后端数据库。）可以将从原型
中获得的经验应用于领域对象并作为对象设计阶段的指导。 

按此在新窗口浏览图片
图3 详细对象分析：订单 

3、 架构规格说明 

经过前面两个步骤，业务领域问题和需求应该比较明确了。现在，我们将工作集中在技术
策略和架构上。架构是指所有构件组合定义系统的一个蓝图：结构、接口和通讯机制。我
们可以进一步将架构分为企业级和应用级架构。 

企业级系统架构 

企业级系统架构包括硬件和软件基础设施、网络布局、开发、测试、生产环境等等。它反
映了一个企业的长期投资。开发前，需要评估已存在的软件和硬件基础设施，如果不完全
支持J2EE的话，增加新构件更新已存在系统。你需要彻底地评估硬件，包括计算机、路由
器、网络转换器和网络布局，因为它们都影响到系统的性能和可靠性。图4 显示了一个可
能的多层网络布局。 

按此在新窗口浏览图片
图4 企业级架构：网络布局 

如图4所示的一个多层企业级架构包括以下几个主要构件： 


一个Web浏览器客户端，可能在也可能不在客户端组织的防火墙内 
一个HTTP服务器，是一个对公众开放的Web服务器。它通常位于一个称作DMZ的子网内 
Web容器主表示层和可能的业务逻辑构件 
应用程序容器主业务逻辑构件 
关系数据库管理系统（RDBMS）和数据库主数据、数据逻辑 


你使用的系统架构类型依赖于安全、性能和可靠性的需求，也依赖于组织的财政状况。在
缺少经验的情况下，也可以适当地从一个修理厂电话订购一台简单地二手计算机。
Internet上有许多开放源代码的操作系统、Web服务器、应用程序服务器和数据库管理系
统。得到这些系统的代价只是几百美元和熬几个通宵。 

象许多华尔街金融机构这样的高端客户也许需要一个连续支持安全、高吞吐量交易和不可
预料网络通讯的系统。在这种情况下，为了容错，通常需要将Web服务器和应用程序服务
器集群配置成一个n层架构。 

还需要评估软件基础设施，包括Web服务器、安全管理软件、应用程序服务器、域名管理
服务器、数据库管理系统和第三方软件构件。如果还没有购买应用程序服务器，选择一个
J2EE供应商将是评估过程的一个重要方面。应该注意到不同的供应商对J2EE的实现程度是
不同的，一些供应商只支持老的J2EE版本。另外，一些Web容器或应用程序容器可能比其
他的速度要快。除了实现J2EE规范外，许多供应商还出售J2EE基础构件或框架。选择一个
稳定的提供支持的 J2EE供应商也非常关键。你可以在系统基础设施层面上购买或开发的
通用功能包括： 


事务 
国际化和本地化 
集群和对象分布 
应用程序性能度量和剖析 
通讯 
工作流管理 
入口和个性化管理 
层对层通讯协议 
安全和防火墙 


应用架构 

应用架构参考一个特定的项目和规范建立在企业级系统架构的上层。在基础设施完成后，
架构师研究怎样构造一个特定的应用。如果你的企业级架构仅部分支持老的 J2EE版本，
可以先升级你的系统。如果由于预算或时间关系不能升级，那么必须在更老版本规定的技
术范围内开展工作。虽然构造企业级重用构件非常重要，但是必须首先要能够使用。这里
的最终目标是满足客户的需求--一次一个项目。 

架构师不是设计师；架构和设计是完全不同。一个应用架构的范围包括系统的主要结构、
架构设计模式和可以在上面增加构件的框架。架构主要关注的是非功能性方面，而设计关
注应用业务用例将领域对象模型转换成技术对象模型。应用架构是项目的结构，一个特殊
的应用程序。通过应用架构开发，你通常必须要做的应用架构决定包括： 


层之间进行功能划分 
领域对象建模 
要保护的遗留系统 
要购买的软件构件 
要开发的构件 
怎样集成第三方构件 


图3的订单领域对象说明了怎样对领域对象进行建模。利用当前的Java技术，可以将领域
对象分布在作为开发者管理持续性对象的Web容器中、应用程序服务器的EJB中或者作为
RDBMS宿主的Java存储过程中。 

在宠物店蓝图中，我们将订单对象设计成一个实体bean，一个详细对象和一个数据访问对
象，如图5和后面的图6所示。当你看到这个的时候，你应该意识到架构的重要性。为什么
分析模型中的一个领域对象映射成这么多对象？如果改变设计，会出现什么问题？你也许
听说过EJB的好处，但是要注意不同供应商的性能是不同的。当一种新技术到来的时候，
你需要在投入全面设计之前进行一些研究。你可以经常地将设计和实现领域对象模型纵向
联合部分的经验应用到其他许多领域对象中。这就是架构开发的内容。 
按此在新窗口浏览图片
图4 企业级架构：网络布局 

如图4所示的一个多层企业级架构包括以下几个主要构件： 


一个Web浏览器客户端，可能在也可能不在客户端组织的防火墙内 
一个HTTP服务器，是一个对公众开放的Web服务器。它通常位于一个称作DMZ的子网内 
Web容器主表示层和可能的业务逻辑构件 
应用程序容器主业务逻辑构件 
关系数据库管理系统（RDBMS）和数据库主数据、数据逻辑 


你使用的系统架构类型依赖于安全、性能和可靠性的需求，也依赖于组织的财政状况。在
缺少经验的情况下，也可以适当地从一个修理厂电话订购一台简单地二手计算机。
Internet上有许多开放源代码的操作系统、Web服务器、应用程序服务器和数据库管理系
统。得到这些系统的代价只是几百美元和熬几个通宵。 

象许多华尔街金融机构这样的高端客户也许需要一个连续支持安全、高吞吐量交易和不可
预料网络通讯的系统。在这种情况下，为了容错，通常需要将Web服务器和应用程序服务
器集群配置成一个n层架构。 

还需要评估软件基础设施，包括Web服务器、安全管理软件、应用程序服务器、域名管理
服务器、数据库管理系统和第三方软件构件。如果还没有购买应用程序服务器，选择一个
J2EE供应商将是评估过程的一个重要方面。应该注意到不同的供应商对J2EE的实现程度是
不同的，一些供应商只支持老的J2EE版本。另外，一些Web容器或应用程序容器可能比其
他的速度要快。除了实现J2EE规范外，许多供应商还出售J2EE基础构件或框架。选择一个
稳定的提供支持的 J2EE供应商也非常关键。你可以在系统基础设施层面上购买或开发的
通用功能包括： 


事务 
国际化和本地化 
集群和对象分布 
应用程序性能度量和剖析 
通讯 
工作流管理 
入口和个性化管理 
层对层通讯协议 
安全和防火墙 


应用架构 

应用架构参考一个特定的项目和规范建立在企业级系统架构的上层。在基础设施完成后，
架构师研究怎样构造一个特定的应用。如果你的企业级架构仅部分支持老的 J2EE版本，
可以先升级你的系统。如果由于预算或时间关系不能升级，那么必须在更老版本规定的技
术范围内开展工作。虽然构造企业级重用构件非常重要，但是必须首先要能够使用。这里
的最终目标是满足客户的需求--一次一个项目。 

架构师不是设计师；架构和设计是完全不同。一个应用架构的范围包括系统的主要结构、
架构设计模式和可以在上面增加构件的框架。架构主要关注的是非功能性方面，而设计关
注应用业务用例将领域对象模型转换成技术对象模型。应用架构是项目的结构，一个特殊
的应用程序。通过应用架构开发，你通常必须要做的应用架构决定包括： 


层之间进行功能划分 
领域对象建模 
要保护的遗留系统 
要购买的软件构件 
要开发的构件 
怎样集成第三方构件 


图3的订单领域对象说明了怎样对领域对象进行建模。利用当前的Java技术，可以将领域
对象分布在作为开发者管理持续性对象的Web容器中、应用程序服务器的EJB中或者作为
RDBMS宿主的Java存储过程中。 

在宠物店蓝图中，我们将订单对象设计成一个实体bean，一个详细对象和一个数据访问对
象，如图5和后面的图6所示。当你看到这个的时候，你应该意识到架构的重要性。为什么
分析模型中的一个领域对象映射成这么多对象？如果改变设计，会出现什么问题？你也许
听说过EJB的好处，但是要注意不同供应商的性能是不同的。当一种新技术到来的时候，
你需要在投入全面设计之前进行一些研究。你可以经常地将设计和实现领域对象模型纵向
联合部分的经验应用到其他许多领域对象中。这就是架构开发的内容。